Update messaging for Migrations and Modernization and detail of engagement#247
Update messaging for Migrations and Modernization and detail of engagement#247brianamarie wants to merge 3 commits into
Conversation
…offer. Locks contracting (Percona wraps, license in engagement), keeps PACE as methodology only, and folds Michal assessment/package accuracy plus hypercare into the capability page. Co-authored-by: Cursor <cursoragent@cursor.com>
New File Governance CheckNo added markdown files detected. Doc Coverage CheckNo new markdown docs detected. Manual waiver commands (maintainers)
Waiver JSON is stored in a hidden PR comment ( Triggered by |
Messaging Smart Suggestions
Only auto-apply suggestions at high confidence with reviewer approval. Triggered by |
Messaging Impact Check
postgres-cost-claim (BLOCKING)PostgreSQL cost/TCO claims usually impact shared value proof messaging. Required review files:
Suggested additional scan:
licensing-or-open-source-claims (BLOCKING)License and open source positioning changes are cross-cutting. Required review files:
Suggested additional scan:
offering-name-or-tier-change (WARN)Offering naming updates should stay aligned across offering pages. Required review files:
Suggested additional scan:
product-messaging-module-touch (WARN)Product messaging modules often need checks against company framing and shared pillars or offerings. Required review files:
Suggested additional scan:
Manual waiver commands (maintainers):
Waiver state is stored in Triggered by |
Scope HexaCluster to proprietary exits (Oracle lead), add Percona accountability through hypercare, soften license wording, and cut false path-split / dual-vendor phrasing. Co-authored-by: Cursor <cursoragent@cursor.com>
Keep same-engine and MongoDB as Percona consulting unless assessment says otherwise, and align tooling copy with non-automated work scoped in assessment. Co-authored-by: Cursor <cursoragent@cursor.com>
mmnosek
left a comment
mmnosek
left a comment
There was a problem hiding this comment.
It confuses me that PACE is pretty much removed in this edit.
| **Assessment-led programs from evaluation to production. One Percona engagement, open source targets, support after go-live.** | ||
|
|
||
| Legacy and proprietary database estates drive renewal pressure, license drag, and operational risk. Percona helps teams assess exit paths, migrate or modernize to open source targets, and stabilize production after cutover with Expert Support on the destination environment. | ||
| Percona delivers Migration and Modernization as one accountable engagement from assessment through cutover, hypercare, and Expert Support. Percona stays present for the full journey, not only the conversion step. |
There was a problem hiding this comment.
I like that, maybe a slight fine-tuning suggestion: "Percona guides you through the whole journey to open source, not only the conversion step. "
This is to higlight that we are a partner that enable your entire organization to move to open source and the conversion is just a one of those steps if that makes sense.
There was a problem hiding this comment.
I'd just cut the second sentence. It's redundant, essentially repeating the first sentence but with vague, overused marketing phrases.
Or, if we're trying to challenge, name the specific thing we're challenging. It seems like we're vaguely alluding that other vendors only do the conversion step - is that true?
| ## Focus migration paths | ||
|
|
||
| Assessment confirms source, target, and deployment model. Common PACE paths include: | ||
| Source and target are typically chosen before assessment begins. Assessment confirms feasibility, change scope, project cost, and post-migration support cost for that path. Common paths include: |
There was a problem hiding this comment.
I think saying that source and target are chosen before the assessment is misleading. I would remove that first sentence and just start with "Assessment". Source is always there for years, and the prospect comes to us with the target rpetty much all the time. We don't choose it for them in practice.
| | MySQL | PostgreSQL, MySQL | | ||
| | MariaDB | PostgreSQL, MariaDB | | ||
| | Cassandra | PostgreSQL | | ||
| | MongoDB Atlas / Enterprise Advanced | Percona Server for MongoDB | |
There was a problem hiding this comment.
I think this is not the space to blend all migrations into one table or offering. It should be about engines (switching engines/technologies). MongoDB -> MongoDB doesn't fit here. If we get into a different hosting model/distribution, this table would be super, super long. (e.g., AWS Aurora -> Percona Server for MySQL, MySQL Enterprise Edition to Percona Server for MySQL, EDB Postgres to Percona Postgres, Crunchy Postgres to Percona Postgres - the list of combinations is endless).
We should stick to:
Oracle -> PostgreSQL, MariaDB
SQL Server -> PostgreSQL
MySQL -> PostgreSQL
MariaDB -> MySQL
Sybase -> PostgreSQL
DB2 -> PostgreSQL
| # Migration and Modernization | ||
|
|
||
| **Assessment-led programs from evaluation to production. One Percona team, open source targets, support after go-live.** | ||
| **Assessment-led programs from evaluation to production. One Percona engagement, open source targets, support after go-live.** |
There was a problem hiding this comment.
What are "assessment-led programs"? This reads like an invented phrase.
I think the point is to say that our experts evaluate migration feasibility and difficulty using tooling and expertise to provide practical migration guidance. For those that are a fit, we're connected the entire time through assessment, execution, hypercare, and ExpertSupport.
IMO, if this is top-level messaging, we should be more specific. As we use this with prompts further down the line, we can target specific audiences or types of collateral and filter this more specific messaging down to things like "evaluation to production".
3 participants
Summary